home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20020314-20021006
/
000405_r..collins@sympatico.ca_Fri Sep 27 17:46:13 EDT 2002.msg
< prev
next >
Wrap
Text File
|
2002-10-06
|
4KB
|
78 lines
Article: 13741 of comp.protocols.kermit.misc
From: "Richard Collins" <r..collins@sympatico.ca>
Newsgroups: comp.protocols.kermit.misc,comp.unix.xenix.sco,comp.dcom.modems
References: <7ea6ad1.0209241717.7af4adc8@posting.google.com> <amsde3$d5d$1@watsol.cc.columbia.edu> <7ea6ad1.0209271119.527a46fc@posting.google.com>
Subject: Re: Help! Trying to send files via serial modem...
Lines: 53
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <ih3l9.9782$ls3.1572990@news20.bellglobal.com>
Date: Fri, 27 Sep 2002 16:31:28 -0400
NNTP-Posting-Host: 64.230.38.27
X-Complaints-To: abuse@sympatico.ca
X-Trace: news20.bellglobal.com 1033158862 64.230.38.27 (Fri, 27 Sep 2002 16:34:22 EDT)
NNTP-Posting-Date: Fri, 27 Sep 2002 16:34:22 EDT
Organization: Bell Sympatico
Path: newsmaster.cc.columbia.edu!newsfeed.nyu.edu!news.maxwell.syr.edu!xmission!snoopy.risq.qc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13741 comp.unix.xenix.sco:18675 comp.dcom.modems:316247
"Ray Ward" <rayward@metronet.com> wrote in message
news:7ea6ad1.0209271119.527a46fc@posting.google.com...
> fdc@columbia.edu (Frank da Cruz) wrote in message
news:<amsde3$d5d$1@watsol.cc.columbia.edu>...
>
>
> I think that rather than dumbing down the central server's modem, I'll
> just let the modems negotiate -- I think all are USR Sportsters, and
should
> negotiate.
>
Jumping in the middle here. "speed mismatch" was mentioned somewhere along
the line. That is a possibility, but you have to remember that there are two
links to consider - the modem-modem (DCE) link and the modem-terminal (DTE)
link. You're right in that the modems will negotiate a common speed between
them, but all kinds of "funnies" can happen between the modems and the
terminal, on the DTE link.
Originally modems provided one speed, and were pretty simple devices - the
port was set to match the modem's speed and all was well. When modems were
introduced that handled multiple speeds (300 or 600 bps, for example) there
was a problem - what speed do you set the port to? The answer was to have
the modem tell the terminal program what speed it connected at - that's why
you have a CONNECT message. The procedure was for the modem to negotiate a
speed with the remote, and then tell its termnal, through the CONNECT
message, what speed it would be using. The CONNECT message was sent at the
speed the port was originally configured to and then:
1) the modem switched its DTE speed to match its DCE speed; _and_
2) the terminal program was expected to change the port speed to match the
speed noted in the CONNECT message.
You'll note that _both_ speeds had to be change if communications beyond
that point were to be successful.
When buffering was added to the modem it was possible to maintain a
different speed on the DCE link than of the DTE link - the buffer, and flow
control, would handle the speed differential. Of course, commands were added
to the modem repetoire to tell the modem whether it should change to the DCE
speed after sending the CONNECT message or not, and since there are
advantages to using a high DTE speed in relation to DCE speed (error
correction and modem compression) the default was for the modem _not_ to
switch speeds. Of course, that meant that the terminal program had to be
instructed to ignore the speed in the CONNECT message and leave the port
alone - otherwise, you would have a speed mismatch and a comm link failure.
You might want to check the settings in your comm programs and the modem
confug to ensure they both agree on whether to maintain a fixed port rate or
not.